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ABSTRACT 


This  represents  CDRL  I tea  A002  for  Rome  Air  Develop¬ 
ment  Center  Contract  F306Q2-81-C-0018*  KVM/370  Tech¬ 
nical  Demonstration*  and  serves  as  a  final  technical 
report  summarizing  work  performed  on  the  preparation 
and  demonstration  of  the  Kernelized  VM/370  security 
desian« 

This  report  presents  the  current  status  and  Plans 
of  the  Kernelized  VM/370  Project  (KVM/370)*  a 

Department  of  Defense  initiative  in  which  a  security 
retrofit  is  beins  performed  on  IBM  Corporation' s 
Virtual  Machine  Facility/370  (VM/370)  system  that 
will  provide  a  time-shared  environment  in  which  user 
processes  bearina  differina  military  classifica¬ 
tion  levels  may  be  operated  simultaneously  with¬ 
out  compromise  to  military  security  policy.  The 
strateay  entails  drawina  toaether  into  a  secure 
kernel  those  system  functions  that  otherwise  could 
be  exploited  to  violate  security.  This  report  de¬ 
scribes  the  principal  results  of  the  first  four 
years  of  this  prosram  and  discusses  our  current 
plans  for  KVM's  future. 

The  report  also  describes  the  first  installation  of 
a  prototype  version  of  KVM*  the  KVM-Alpha  Release* 
at  a  aovernment  test  site.  The  report  includes  pre¬ 
liminary  benchmark  test  results  obtained  at  that 
site*  the  Naval  Air  Test  Center  at  Patuxent  River* 
Maryland . 
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1.0  INTRODUCTION 

# 

The  priaary  doal  of  the  KVM/370  Prodraa  is  the  security  retrofit  of  a 
popular  coaaercial  operatind  system  (VM/370)  into  a  secure  system  that 
will  be  certified  for  use  as  a  trusted  coaputind  base  in  support  of 
multi-level  classified  data  processind  environments.  The  KVM/370 
Prodraa  is  a  research  and  developaent  initiative*  oridinally  funded  by 
the  Defense  Advanced  Research  Projects  Adency  ( DARPA ) *  and  continuind 
under  the  auspices  of  the  Departaent  of  Defense  Coaputer  Security  Initi¬ 
ative.  Contract  adainistration  transitioned  to  the  Air  Force  Ueapons 
Laboratory  and  the  Roae  Air  Developaent  Center  as  the  project  aatured 
into  its  current  iapleaentation  and  testind  activities.  The  project  is 
now  funded  and  adainistered  by  the  Rose  Air  Developaent  Center. 

This  report  is  ordanized  in  three  aaJor  sections.  We  bedin  by  divind  a 
short  aotivational  history  of  the  project.  We  then  present  a  brief  dis¬ 
cussion  of  the  KVM  architecture.  We  conclude  with  a  report  on  the 
current  status  and  plans  for  KVM.  The  latter  report  includes  a  descrip¬ 
tion  of  the  installation  of  the  KVM-Alpha  Release  at  the  Naval  Air  Test 
Center*  Patuxent  River*  Maryland*  and  preiiainary  rerforaance  character¬ 
istics  of  the  prototype  system  that  were  observed  at  the  test  site. 

2.0  HISTORICAL  OVERVIEW 

In  the  late  1960's*  the  AQP  coaaunity  becaae  conscious  of  the  need  to 
protect  sensitive  data  from  access  by  users  who  were  authorized  to  use 
the  computind  resource  but  did  not  have  a  Justifiable  *need-to-know*  for 
all  of  the  data  accessible  from  that  resource.  It  was  also  apparent 
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that  many  of  the  existing  operating  systems  offered  no  direct  protection 
of  files  fro*  casual  browsing  by  the  user  population*  Worse*  even  those 
swstees  in  which  soee  fora  of  protection  (e.g**  passwords  or  access 
control  lists)  was  part  of  the  design  appeared  to  be  impotent  to  prevent 
the  success  of  aalicious  attempts  to  access  such  data*  At  this  time* 
SDC  was  awarded  a  DARPA  contract  that  resulted  in  the  implementation  of 
the  first  general  purpose  multi-user  time  sharing  system  explicitly 
designed  to  enforce  a  formally  specified  security  policy  model*  C133<1> 
This  system*  ADEPT-30*  was  reasonably  good  at  defending  against  direct 
penetration  attempts*  but  succumbed  to  more  sophisticated  indirect 
attacks  it  was  not  designed  to  protect  against* 

At  the  inauguration  of  the  last  decade*  SDC  performed  research  studies 

» 

as  a  pioneer  in  the  evolving  computer  security  community.  The  majority 
of  work  being  done  at  that  time  centered  heavily  on  security  analyses 
and  penetration  studies  of  computer  operating  systems*  When  it  was 
first  conjectured  that  a  formal  penetration  methodology  could  be  devel¬ 
oped  to  identify  generic  security  flaws  in  such  systems*  SDC  commenced 
an  investigation  into  the  viability  of  the  Virtual  Machine  Monitor  (VMM) 
concept  C2*  33  as  a  certifiable  means  of  achieving  secure  isolation  of 
user  processes  on  a  common  mainframe* 

In  1974-5*  the  Systems  Security  Department  of  SDC's  Research  and  Devel¬ 
opment  Division  performed  a  study  with  and  at  the  remuest  of  the  IBM 
Thomas  J*  Watson  Research  Laboratory.  The  objectives  of  the  study  were 

<1> 

Numbers  in  brackets  refer  to  bibliographic  entries  in  the  Refer¬ 
ences  Section  of  this  report* 
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(1)  To  derive  a  scientific  approach  to  the  identification 

of  security  flaws  in  operating  systems)  and 

(2)  To  evaluate  the  security  properties  of  the  MM/370 

system* 

The  results  of  the  completed  study  included  analysis  criteria  that  are 
best  known  as  the  SDC  Flaw  Hypothesis  Methodology  (FHM)C1S3*  and  a 
detailed  enuaeration  of  hypothetical  and  verified  security  flaws  in  the 
conaercial  Release  2*0  version  of  MM/370*C13 

The  FHM  was  subseouently  successfully  applied  to  the  security  analysis 
of  a  nuaber  of  other  coaaercial  operating  svsteas.  However*  the  securi¬ 
ty  properties  of  MM/370  stood  out  as  exceptional  evidence  of  the  vali¬ 
dity  of  the  MMM  hypothesis*  The  Mirtual  Machine  Monitor  concept  is  so 
fundaaentally  siaple  that  it  is  iapleaented  in  MM/370  by  a  body  of  code 
that  comprises  less  than  100*000  assembly  language  instructions*  This 
body  of  code  is  called  the  MM/370  Control  Program  (CP)*  Its  function  is 
the  simulation  of  the  privileged  portion  of  an  IBM  S/370  computer*<2> 
MM/370-CP  had  far  fewer  security  flaws  than  any  other  operating  systen 
we  have  examined*  Many  of  these  flaws  were  actually  flaws  present  in  the 
IBM  S/370  architecture  itself*  perfectly  simulated  by  the  Control 
Program  for  exploitation  by  the  penetrator* 

In  1976*  SDC  was  awarded  a  study  contract  by  the  Defense  Advanced 
Research  Projects  Agency*  The  primary  purpose  of  the  study  was  to  ana- 

<2> 

Later  commercial  releases  of  MM/370  are  significantly  larger  than 
this*  but  the  majority  of  additional  code  is  present  for  the  support  of 
new  1/0  devices*  having  essentially  no  effect  on  the  overall  logic  or 
functionality  of  the  Control  Program* 
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laze  the  feasibility  and  cost/effectiveness  of  designing  and  implement¬ 
ing  a  certifiable  security  retrofit  to  VM/370.  The  underlying  concepts 
behind  the  project  were  fairly  simple* 

(1)  The  security  relevant  operations  on  an  S/370  are  a 
proper  subset  of  the  privileged  operations  on  an 
S/370 ? 

<2)  All  privileged  operations  in  VM/370  are  simulated  by 
the  Control  Program? 

(3)  Therefore  CP*  if  correctly  implemented*  could  en¬ 
force  a  security  policy  over  all  virtual  machines  as 
a  reference  monitor*C43 

(4)  However*  a  certifiable  reference  monitor  must  be 
sufficiently  small  and  simple  as  to  be  'verifiably' 
correct  in  its  functionality*  and  even  at  100*000 
instructions*  CP  was  too  large  to  verify  by  formal 
state-of-the-art  means* 

(5)  It  should  be  possible  to  partition  CP  into  its  secu¬ 
rity  relevant  and  its  non-security  relevant  compo¬ 
nents  such  that  the  former  would  fora  a  smaller  and 
simpler  Security  Kernel* 

(6)  This  Kernel  would  be  rewritten  in  a  'verifiable' 
high  order  language  and  formal  argument  would  be 
produced  to  substantiate  the  claim  that  the  Kernel 
enforced  a  security  policy  as  an  implementation  of 
the  Reference  Monitor  Concept*C43 

(7)  Only  the  Kernel  would  execute  in  Privileged  Mode*  so 
only  the  Kernel  would  be  capable  of  performing  secu¬ 
rity  relevant  operations  (because  of  hardware 
enforcement) ? 

(8)  The  remainder  of  CP  (the  Non  Kernel  Control  Program* 
or  NKCP)  could  essentially  remain  unchanged  except 
for  the  reouirement  that  it  operate  in  problem  state 
and  properly  interface  with  the  Kernel*  thus  elim¬ 
inating  the  cost  and  risk  of  implementing  an  en¬ 
tirely  new  system*  and  finally* 

(9)  Since  the  Kernel  and  NKCP  would  together  simulate 
CP*  most  applications  that  could  operate  under 
VM/370  would  also  operate  under  the  new  Kernelized 
system  KVM/370. 


During  this  phase  of  the  study*  the  SDC  researchers  war*  in  active  con¬ 
tact  with  the  DARPA  Computer  Security  Working  Group  and  with  an  over¬ 
sight  committee  of  other  Governeent-selected  computer  security  experts* 
As  a  result  of  interaction  with  these  groups*  the  emerging  KVM  security 
architecture  was  subjected  to  thorough  peer  review  on  a  Quarterly  basis 
for  somewhat  more  than  the  first  two  years  of  its  evolution*  Joint 
initiatives  by  SDC  and  the  Department  of  Defense  resulted  in  periodic 
interactions  between  the  SDC  researchers  and  the  IBM  VM/370  Development 
Group*  The  product  of  our  labors  and  the  helpful  criticisms  given  us 
during  the  reviews  was  the  design  and  formal  specif ication  of  KVM/370 
that  were  published  in  the  Spring  of  1978*  at  which  time  DARPA  awarded 
SDC  an  implementation  contract  for  the  development  of  a  KVM  proto¬ 
type.  <3> 

A  preliminary  version  of  the  KVM  prototype  was  demonstrated  to  a  select 
group  of  DoD  personnel  in  October*  1979*  An  Alpha-test  version  of  the 
prototype  was  installed  at  the  Naval  Air  Test  Center*  Patuxent  River* 
Maryland  in  April  1981  for  preliminary  testing  and  measurement*  Planned 
measurement  tasking  includes  some  analysis  of  user  acceptance  of  the 
security  interface  to  the  system*  in  addition  to  the  all-important 
measurement  of  system  throughput.  Data  obtained  from  the  Alpha  test 
site  will  be  used  to  identify  system  bottlenecks*  and  serve  as  a  basis 
for  tuning  (optimizing)  the  performance  of  the  ultimate  system*  It  is 

<3> 

The  interested  reader  is  referred  to  C1&*  173  for  a  more  detailed 
treatment  of  *he  KVM  a  chitecture  and  its  rationale  than  is  presented  in 
this  report. 


planned  that  a  test  version  of  the  prototype  system*  the  KVM-Beta 
Release*  will  be  installed  at  selected  dovernaent  sites  in  the  late 
Serins  of  1982  for  aore  intensive  testind  and  user  evaluation*  At  that 
tiae*  the  foraally  verified  specification  of  KVM*  alond  with  all  swstea 
docuaentation*  will  be  delivered  to  the  Governaent  in  order  that  KVM  aay 
be  considered  for  certification  to  operate  in  a  aulti-level  environaent* 


3.0  KVM  ARCHITECTURAL  CONSIDERATIONS 

3.1  Retrofit  St rated* 

A  methodology  was  developed  for  partitioning  the  VM/370  control  rrodraa 
(VM/370-CP)  into  security  relevant  and  non-security  relevant  aodules. 
The  decision  process  is  based  on  the  principles  of  least  rrivilese  and 
least  coaaon  aechanisa.  It. defines  security  relevant  code  in  CP  as  that 
code  which  executes  rrivileded  instructions  or  the  code  which  accesses 
dlobal  swstea  data  (e.d.*  the  control  blocks  used  to  support  processes 
on  the  real  aachine  necessarily  contain  data  from  all  security  levels). 
Usind  this  definition*  security  relevant  CP  nodules  are  directly  iden- 
tif table. 

It  was  found  that  nost  CP  system  data  need  not  be  truly  dlobal*  but 
dlobal  only  over  the  VMs  operatind  at  a  diven  security  level.  The  VMs 
at  a  diven  security  level<4>  could  be  supported  by  a  coabination  of  a 

<4> 

The  reader  is  referred  to  Section  3.2  for  an  explanation  of  the 
security  level  concept* 
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formally  verified  Kernel  operating  in  real  supervisor  state  and  a  Non- 
Kernel  Control  Program  (NKCP)  executing  in  real  problem  state  and 
consisting  of  eost  of  the  non-security  relevant  VM/370-CP  code.  The 
NKCP  would  execute  as  a  virtual  machine?  having  access  only  to  global 
system  data  for  the  virtual  aachines  it  is  supporting  at  its  security 
level . 


The  reader  should  note  the  significant  difference  between  a  security 
retrofit  to  VM/370  and  a  new  design  of  a  secure  VM/370.  In  both  cases 
it  is  necessary  to  design  and  specify  the  security  enforceeent  Mecha¬ 
nises  far  the  security  Kernel ?  as  well  as  to  derive  the  set  of  foreal 
security  invariants  the  Kernel  oust  preserve  over  the  systee.  It  is 
found?  however?  that  auch  of  the  code  in  an  operating  systea  that 
virtualizes  a  computer?  such  as  that  found  in  VM/370-CP?  either  has  no 
security  relevance  or  can  be  trivially  eodified<5>  so  that  it  no  longer 
has  any  security  relevance.  Hence?  auch  of  the  existing  code  which 
provides  functional  capabilities  to  the  virtual  aachines  is  essentially 
usable  as  it  stands. 


<5> 

While  these  modifications  are  straight-forward?  there  does  remain 
the  more  difficult  task  of  interfacing  the  old  code  and  data  structures 
with  the  Kernel  and  its  redesigned  data  structures.  It  was  found  that 
considerable  planning  was  reouired  in  order  that  the  interface  could 
evolve  smoothly  during  actual  implementation.  Control  and  flexibility 
were  achieved  through  the  creative  and  Judicious  use  of  macros  and  CMS 
EXECs.  The  project  did  not  attempt  a  parallel  effort  of  performing  a 
direct  reimplementation  of  VM  in  lieu  of  the  retrofit?  so  there  is  no 
empirical  data  with  which  to  compare  levels  of  effort  for  future  related 
endeavours  on  other  operating  systems. 
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Secondly*  such  code*  in  fact  all  of  VM/370*  can  be  virtualized*  A 
strategy  derived  fro*  these  observations  involves  designing  and  verify¬ 
ing  a  relatively  seall  body  of  code  which  is  Just  powerful  enough  to 
provide  primitive  virtualization  and  which  controls  all  forns  of  I/O 
access  in  compliance  with  the  security  policy*  It  is  thus  conceptually 
possible  to  run  numerous  copies  of  VM/370  atop  this  simple  kernel*  each 
running  in  virtual  supervisor  state*  Since  the  Kernel  is  the  final 
arbiter  and  all  access  to  real  devices  must  eventually  pass  through  it 
(these  accesses  all  reouire  invocation  of  privileged  instructions* 
i.e.*  real  supervisor  state)*  no  action  of  the  virtualized  VM/370-CP 
can  compromise  security*  The  users  would  run  their  programs  atop  the 
untrusted  copies  of  virtualized  VM/370.  If  a  virtualized  VM/370-CP  were 
to  attempt  to  perform  actions  contrary  to  the  security  policy*  the 
Kernel  would  prohibit  such  actions  fro*  taking  place*  These  potential 
denials  of  service  could  be  avoided  by  deleting  the  related  code  from 
the  virtualized  VM/370~CPs»  but  it  is  important  to  observe  that  these 
matters  have  no  effect  upon  the  enforcement  of  security  since  (1)  the 
Kernel  would  have  been  designed  to  enforce  a  specific  security  policy* 
(2)  the  Kernel  would  have  been  formally  verified  to  support  the  enforce¬ 
ment  of  that  policy*  and  (3)  the  correctness  proof  of  the  Kernel  made 
no  assumptions  about  any  of  the  virtual  machines  running  atop  the 
Kernel*  particularly  none  with  respect  to  an  NKCP  itself. 

In  the  interest  of  enhancing  the  performance  of  such  a  Kernelized 
system*  it  would  be  necessary  to  give  certain  system  modules  access  to 
multi-level  system  data.  These  are  the  modules  which  control  the 
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sharing  of  rail  systea  rasourcas  aaong  virtual  aachinas  at  diffarant 
security  levels.  In  order  to  aaintain  suttee  security?  it  is  neces¬ 
sary  to  ascertain  that  such  resource  aanageaent  aodules  properly  use  the 
privileges  granted  thea  by  the  added  coaaon  aechanisa*  Such  aodules 
becoae  'Trusted  Processes*.  Where  possible  and  practical?  the  Trusted 
Processes  are  to  be  given  the  saae  foraal  verification  the  Kernel 
Processes  should  receive. 

Where  this  is  not  practical  or  Possible?<6>  the  Trusted  Processes  aust 
be  subjected  to  a  thorough  integrity  audit?  encapsulated  into  a  liaited 
address  space?  and  restricted  so  that  they  operate  in  real  problea  state 
with  virtual  addresses.  These  latter  processes  are  known  as  Global 
Processes* 

3*2  Security  Policy 

The  KVM/370  Kernel  is  designed  to  enforce  a  foraal  aodel  of  the  ailitary 
security  policy*  This  reeuires  the  preservation  of  two  security  condi¬ 
tions?  the  'Security  Property'?  and  the  'Confineaent  Property*  (or  •*- 
Property '). C9?  103  These  properties  are  described  in  teras  of  three 
types  of  entities:  subjects?  objects  and  security  levels*  Subjects 
are  the  active  eleaents  of  the  systea  for  which  data  access  aust  be  con- 


<6> 

The  Global  Processes  serve  as  schedulers  and  allocators  of  global 
resources  and  have  the  potential  to  be  used  as  an  illicit  signalling 
path  in  violation  of  the  NITRE  Confineaent  Property  by  aodulating  the 
global  state  variable?  tiaa.  There  is  no  known  aethod  for  foraally 
deaonst rating  that  an  alsorithaical lv  correct?  TroJan  Horse-free? 
scheduler  cannot  be  aanipulated  by  users  in  such  a  way  that  the  users 
can  cause  clock  time?  to  becoae  a  signal  to  other  users. 
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trolled  (e.s.*  ut«rs»  processes) •  Objects  are  the  data  or  data  con¬ 
tainers*  access  to  which  oust  be  controlled  bv  the  Kernel*  There  is  a 
security  level  associated  with  each  subject  or  object*  The  security 
level  of  a  subject  represents  the  suoJect's  'security  clearance'* 
servins  as  a  aeasure  of  the  level  of  trust  Placed  in  the  subject)  the 
security  level  of  an  object  represents  the  object's  classification*  A 
security  level  <C*K>  consists  of  two  components:  a  hierarchical  classi¬ 
fication  C  from  the  ordered  set  -CUnclassif ied*  Confidential*  Secret* 

Top  Secret}*  and  a  catesory  K  consisting  of  a  subset  (possibly  eepty)  of 
the  set  of  special  access  coapartaents.<7> 

The  Security  Condition  reouires  that  no  subject  eay  access  an  object  for 

I 

the  purpose  of  rea dine  or  updatins  unless  the  security  level  of  the 
subject  dominates  that  of  the  object. <8>  The  Confinement  Property 
demands  that  a  subject  may  have  write  access  to  an  object  (permission  to 
both  read  and  write)  only  if  the  security  level  of  the  subject  and 
object  are  precisely  the  same  security  level. <9> 


A  security  level  SL1  is  said  to  'dominate*  a  security  level  SL2  if 
the  hierarchical  component  of  SL1  is  at  least  as  hiah  as  the  hierarchi¬ 
cal  component  of  SL2  and  all  of  the  compartments  of  SL2  are  contained  in 
the  compartments  of  SH*  The  two  security  levels  are  called  'non¬ 
comparable*  if  the  compartments  of  SL1  are  not  a  subset  of  those  of  SL2 
and  those  of  SL2  are  not  a  subset  of  those  of  SL1*  Therefore*  the  domi¬ 
nates  relation  is  a  partial  order  on  security  levels. 

<8> 

If  the  security  levels  of  the  subject  and  the  object  are  non¬ 
comparable*  then  the  subject  cannot  obtain  read  access  to  the  object* 
even  if  the  subject's  hierarchical  security  level  is  hisher  than  that  of 
the  object* 


National  Security  Policy  reouires  that  a  subject*  in  addition  to 
possessing  the  proper  security  clearance*  must  have  an  appropriate  ‘need 
to  know*  for  the  data  in  any  classified  object  to  which  he  is  to  be 
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In  the  main* 


subjects  in  KVH/370  are  interpreted  as  tha  individual 


NKCPs.  Tha  Kernel  providas  isolation  among  tha  NKCPs*  but  providas 
littla  or  no  additional  isolation  batwaan  VHs  undar  tha  saaa  NKCP  beyond 
that  already  provided  in  VH/370.  Since  all  VHs  operating  undar  tha  saaa 
NKCP  act  at  tha  saaa  security  level*  tha  Kernel  protects  each  VH  froa 
other  VHs  at  different  security  levels*  but  not  necessarily  froa  VHs  at 
tha  saaa  level*  Global  Processes*  which  aust  interface  with  several 
NKCPs  at  different  levels*  are  also  treated  as  subjects* 

The  objects  in  KVH/370  are  collections  of  data  areas  on  DASD  devices  (or 

the  entire  DASD  voluae) *  tape  voluaes*  unit  record  devices*  real  core 

pages*  processes*  and  VH  working  environaents  (control  blocks*  scratch 

storage*  registers*  etc*). 

• 

The  evolution  of  United  States  National  Security  Policy  has  been  moni- 
tored  closely  in  order  to  aake  KVH/370  aore  responsive  to  the  realistic 
needs  of  Governaent  agencies.  Recent  aodif ications  to  this  policy* 
docuaented  in  Executive  Order  12065*  DoD  5200. 1R*  and  Air  Force  Regula¬ 
tion  300-8*  aake  it  clear  that  although  computer  systems  aust  not  di¬ 
vulge  information  to  unauthorized  individuals  the  overclassif ication  of 
data  is  also  prohibited.  KVH/370  enforces  the  Confinement  Property  to 
prevent  unauthorized  declassification  of  data*  and  produces  detailed 
historical  collateral  classification  information  for  every  new  voluae 
created  bw  the  system*  This  access  record  should  help  establish  a  cred- 

accorded  access.  This  latter  reouirement  is  a  form  of  discretionary 
access  policy*  and  is  enforced  in  KVH  through  the  use  of  passwords*  as 
in  VH/370*  and  through  the  use  of  access  control  lists.  These  controls 
are  maintained  and  enforced  by  the  Kernel. 
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ibis  data  classification  as  a  function  of  tha  classifications  of  all 
data  fro*  which  tha  virtual  machine  that  craatad  it  had  access.  This 
historical  classification  information  saw  than  ba  raviawsd  bv  a  sacuritw 
officar  possessing  original  classification  authoritw  in  ordar  to  deter- 
nina  tha  appropriate  classification  for  tha  data* 


3*3  Ovarall  Swstaa  Architactura 


Tha  architactura  of  Karnalizad  VM/370  <KVM/370)?  consists  of  tha  follow- 
ins  domains! 

1*  Tha  Karnal  and  varifiad  Trustad  Processes ?<10>  exe- 
cutins  in  raai  supervisor  state* 

2*  Tha  auditad  Global  Processes?  havins  access  to  soma 
Slobal  swstaa  datar  axacutins  in  raal  problem 
state*  but  havins  access  onlw  to  virtual  addresses? 

3.  Tha  NKCPs?  one  ear  sacuritw  laval?<ll>  havins 


<10> 

At  tha  time  of  KVM's  dasisn?  wa  distinsuishad  between 
Karnal  and  Trustad  Process*  Our  distinction  was  related  to 
verification  dependencies*  Tha  KVM  Trustad  Processes  are 
subject  to  modification  more  freouentlv  than  tha  rest  of  tha 
Kernel?  since  thaw  implement  losin  protocols?  accountins  also- 
rithms?  tha  KVM  sacuritw  policw?  etc**  Thaw  are  desisned  so 
that  tha  Kernel's  formal  verification  is  not  influenced  bw 
modifications  in  Trustad  Process  modules*  Consaauantlw?  if  a 
Trusted  Process  is  modified?  our  design  discipline  reauires 
that  onlw  it  ba  raverifiad. 

Other  investigators  do  not  make  this  distinction?  and  would 
interpret  our  Trustad  Processes  as  part  of  tha  Karnal?  since 
both  are  accorded  tha  same  level  of  formal  verification. 
Under  tha  definitions  used  bw  tha  other  investigators?  KVM's 
Global  Processes  would  ba  called  'Trusted  Processes'  or  'Non 
Kernel  Sacuritw  Related'  (NKSR)  Software. 

For  historical  consistencw?  KVM  will  continue  making  the 
distinction. 

<11> 

Here?  of  course?  we  mean  one  NKCP  data  area  per  sacuritw 


access  to  svstee  data  for  ths  supported  security 
level  onlw»  executins  in  real  problee  state*  bavins 
access  only  to  virtual  addresses) 


4.  The  user  VNs*  each  controlled  by  the  appropriate 
NKCP  for  its  security  level*  executins  in  real 
problee  state* 

Foraal  specifications  for  the  KVM/370  security  Kernel  and  the  four 
Trusted  Processes<12>  were  written  in  the  SDC  foreal  specification 
lansuase  Ina  Jo*  £183<13>  The  specifications*  written  at  a  comprehen¬ 
sive  level  of  abstraction*  are  docueented  in  the  SDC  TH-6062  series* 

It  was  intended  that  all  Kernel  code  and  Trusted  Process  code  would  be 
written  in  a  stronsly  typed  Pascal-based  prosraeeins  lansuase  such  as 
the  EUCLIDC33  lansuase  in  order  to  facilitate  foraal  verif ication. 

However*  as  the  tiae  for  system  implementation  drew  near*  it  was  found 
that  there  were  no  available  production  Quality  compilers  for  EUCLID  or 
any  other  suitable*  verifiable  prosramains  lansuase  that  would  permit 
efficient  system  prosrammins  on  an  XBM/370  machine  base*  The  reaui re¬ 


level*  The  NKCP  code  is  implemented  reentrantly*  and  is  sen- 
erally  resident  in  a  uniaue  copy* 

<12> 

These  trusted  processes  are*  The  Authorization  Process*  controllins 
Losin*  user  authentication*  the  interpretation  of  Security  Policy  for 
the  entire  system*  and  the  manasement  and  allocation  of  unit  record 
devices  between  security  levels)  The  Updater  Process*  which  maintains 
the  security  profile  data  base  used  by  the  Authorization  Process*  and 
communicates  with  the  system  security  officer)  The  Operator  Process* 
which  provides  services  for  the  operator  of  the  real  computer)  and  the 
Accountins  Process*  which  produces  bills  for  computer  services  while  not 
servins  as  a  hish-bandwidth  illicit  communication  channel  for  would-be 
interlopers* 

<13> 

Ina  Jo  is  a  Trade  Hark  of  the  System  Development  Corporation* 
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ment  that  the  system  prosraaains  lansuase  permit  addressing  and  aani" 


pulatins  IBH/370  dependent  data  structures  is  essential  since  the  Kernel 
•ust  anal«ze»  rrerare*  and  eaintain  numerous  tables  and  control  blocks 
whose  structure  is  dictated  bw  the  hardware*  In  order  to  provide  for 
the  future  verification  and  certification  of  KVM/370*  it  is  desirable 
that  a  aaxiaua  of  detail  on  the  manipulation  of  these  data  structures  be 
expressed  in  the  hisher-order  lansuase  rather  than  in  assembly  lansuase 
and  that  the  coepiler  reliably  produce  efficient  executable  coder  lest 
the  perforeance  costs  of  the  swstea  be  iepractically  hish.  It  is  also 
necessary  that  the  coapiled  code  not  reouire  a  run-tiae  support  package 
for  its  execution*  since  the  run-tiae  package  could  be  a  possible 
source  of  security  coaproaise* 

After  serious  consideration  of  nuaerous  lansuases  for  which  coapilers 
either  existed  or  were  proposed*  it  was  decided  by  DARPA  that  systea 
efficiency  was  sufficiently  iaportant  to  perait  the  use  of  a  prosraaains 
landuade  that  was  not  Pascal-based*  providins  it  satisfied  the  other 
exisencies  of  the  project* 

The  lansuase  selected  for  the  iapleaentation  of  KVM/370  was  the  J3  dia¬ 
lect  of  the  JOVIAL  Prosraaains  Lansuase*  whose  optiaizins  coapiler  is 
in  use  on  the  AUACS  proJectClll.  JOVIAL  was  not  desisned  to  support 
foraal  verification*  Conseouently *  while  the  foraal  specif ications 
of  KVM/370  are  currently  beins  formally  verified  asainst  the  security 
policy  enforceaent  criteria*  the  first  iapleaentation  will  not  be 
formally  verified*  Subseouently *  when  a  production  ouality  coapiler 
exists  for  a  verification-oriented  systems  prosraaains  lansuase* 

KVM/370  could  be  recoded  in  that  lansuase  and  then  verified* 
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In  the  meantime*  risourous  prosrammins  conventions  were  established  for 
producing  JOVIAL  code  from  the  foreal  Ina  Jo  specifications*  In 
particular*  data  templates  were  produced  for  mapping  Ina  Jo  data  struc¬ 
tures  into  JOVIAL  tables  according  as  they  were  larse  or  small*  and 
densely  or  sparselw  populated*  Similarly*  codins  teeplates  were 
produced  for  reference  conditions*  existentially  and  universallw  Quan¬ 
tified  expressions*  etc*  Where  practicable  and  within  the  con¬ 
straints  of  the  compiler's  swebol  tables*  nasinS  conventions  for  Ina 
Jo  state  variables  were  transferred  directlv  to  the  correspondins 
JOVIAL  variable  identifiers.  In  this  waw*  attempts  were  eade  to  main- 
tain  an  inforeal  correspondence  between  the  foreal  specifications  and 
all  trusted  code. 

3.3.1  Desisn  Tradeoffs 

The  user's  swstee-use  expectations  influenced  the  KVM  architecture* 
size  of  the  Kernel  and  Trusted  Processes*  overall  swstee  performance* 
and  level  of  effort  reauired  for  implementation  and  formal  verification. 
Resource  scheduling  and  manasement  can  be  performed  on  either  a  system- 
global  or  an  NKCP-local  basis.  If  done  on  a  system-global  basis*  the 
size  of  the  Kernel  and  Trusted  Processes  is  increased*  the  interfaces 
between  the  NKCPs  and  the  slobal  processes  become  more  intricate*  veri¬ 
fication  becomes  more  difficult  and  costly*  system  modification  becomes 
less  facile*  but  system  performance  improves.  If  done  on  a  local 
basis  with  most  resource  manasement  decisions  performed  by  the  NKCPs 
and  perfunctory  reconciliations  performed  bw  the  Kernel*  the  opposite 
results  hold)  system  desisn*  implementation*  verification  and  inter- 
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faces  are  simplified* 


while  system  performance  may  be  adversely 


affected* 

In  terms  of  Greatest  all-around  adaptability  to  applications*  ease  of 
implementation  and  verif ication*  and  best  multi-level  security*  we 
concluded  that! 

t  DASD  rase  areas  will  be  mlobal? 

*  Main  patfe  fram*  management  will  be  based  on  slobal 
allocation  with  mloLal  rase  replacement* 

*  Multi-Level  etvei'-ad  reentrant  systems  will  be  pro¬ 
vided  with  all  shared  pames  locked  into  core? 

*  The  CPU  will  fce  scheduled  bw  the  NKCPs. 

3.3.2  Kernel  and  Trusted  Process  Design 

The  Kernel  and  Trusted  Processes  ace  the  portions  of  KVM/370  whose 
formal  specifications  are  beina  formally  verified.  The  system  has  been 
designed  such  that  there  are  no  'upward*  functional  dependencies  (i.e.* 
no  function  at  level  of  abstraction  i  depends  on  any  function  from  level 
of  abstraction  J  for  its  correct  operation  »  if  i  <  J)  C63  and  C73. 
In  this  way*  it  can  be  demonstrated  that  no  trusted  code  depends  on  the 
correctness  and  non-maliciousness  of  any  untrusted*  unverified  code. 
Further*  the  formal  verification  of  KVM/370  will  reouire  only  that  (1) 
the  Kernel  and  Trusted  Processes  be  shown  to  satisfy  the  reauirements  of 
enforcing  the  security  policy*  and  <2>  the  absence  of  unauthorized 
sisnallina  capabilities  within  the  Global  Processes  be  demonstrated. 

In  the  case  of  the  Start  I/O  reauest  to  the  Kernel*  the  entire  channel 
control  program  is  copied  into  a  portion  of  the  Kernel's  domain  where  it 


t 


is  protected  from  modification  by  asynchronous  attack*  Address  trans¬ 
lation  is  performed  on  the  channel  program.  Then  it  is  legality-checked 
be  the  Kernel  to  guarantee  that  the  program  performs  only  valid 
accessesf  that  all  referenced  pages  are  locked  into  core*  and  that  the 
channel  program  is  not  self-modifying  and  contains  no  puns  or  other 
security  threatsC63*  The  1/0  scheduler  is  then  invoked  and  control  is 
eventually  passed  to  the  dispatcher  nodule*  simulating  an  I/O  Fast 
Release*  When  the  I/O  interrupt  finally  takes  place*  the  relevant 
eases  are  unlocked*  and  the  condition  code  is  passed  as  an  interrupt  to 
the  appropriate  NKCP. 

Each  security  level  has  a  uniaue  address  space  for  use  by  its  NKCP. 
With  the  exception  of  the  functions  enumerated  below*  no  NKCP  can  com- 
municate  outside  its  address  space  or  its  VMs'  address  spaces*  Spool 
files*  virtual  channel-ta-channei  adapters  <CTCA>*  and  inter-VH 
messages  are  handled  by  the  NKCP  and  conseouently  cannot  violate  the 
Kernel's  enforcement  of  the  security  policy* 

The  notable  exceptions  are! 

*  Append-up  for  writing  machine  error  records  and 
accountine  data  which  are  processed  at  the  highest 
security  level  in  the  system) 

*  Read-down  to  obtain  access  to  a  DASD  whose  classifi¬ 
cation  is  dominated  by  the  clearance  of  the  user's 
VM. 

For  purposes  of  design  simplicity*  each  NKCP  will  appear  to  be  uninter¬ 
ruptible  Just  as  VM/3 70-CP  currently  is*  i.e.*  the  NKCP's  critical 
regions  will  be  preserved*  The  NKCP  aay*  in  practice*  be  interrupted 
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by  the  Kernel*  but  only  if  no  NKCP  shared  variable  (e.g.»  its  set  of 
active  page  frames  or  real  addresses)  is  modified  while  it  is  servicing 
a  user  remuest*  This  constraint  on  NKCP  shared  variables  is  the  result 
of  considerable  effort  in  the  area  of  Kernel-NKCP  interaction*  An  NKCP 
terminates  a  critical  region  (a  locally  uninterruptable  code  segment) 
when  it  either  schedules  a  VN  < issues  an  LPSU)  or  when  it  issues  an  I/O 
reouest. 

3.3*3  NKCP  Design  Considerations 

The  overall  architecture  for  KVM  provided  us  with  little  insight  from 
which  to  do  about  performing  the  security  retrofit*  We  knew  that  we  had 
to  formally  specify*  design  and  implement  the  security  relevant  portions 
of  CP  as  the  Kernel  and  Trusted  Processes*  and  to  modify  the  remainder 
of  CP  into  NKCP  and  the  Global  Processes  such  that  the  latter  did  not 
contain  security  relevant  code*  The  remaining  difficult  problems  were 
discovering  the  right  definition  of  'security  relevant  function'*  iden¬ 
tifying  the  associated  code*  and  determining  an  efficient  means  of 
interfacing  the  security  relevant  and  non-security  relevant  components 
of  the  resulting  system. 

Our  initial  belief  was  that  all  privileged  instructions  were  security 
relevant  since*  in  order  to  execute  them*  a  process  had  to  be  in  (the 
highly  security  relevant)  supervisor  state*  While  this  potential  viola¬ 
tion  of  the  Least  Privilege  Principle  is  security  relevant*  it  neither 
identifies  all  security  relevant  operations*  nor  is  it  sufficiently 
fine-grained  to  be  of  practical  use  —  since  CP  simulates  the  privileged 


portion  of  an  S/370*  it  has  a  high  and  uniformly  distributed  number  of 
occurrences  of  privileged  instructions* 

Ultimately  we  arrived  at  the  following  working  definition:  Code  is 
security  relevant  if  it  can  influence  uneediated  I/O  directly  through 
the  use  of  privileged  instructions  that  manipulate  devices  or  user 
domains*  or  indirectly  through  the  use  of  data  structures  that  either 
contain  security  enforcement  data  or  can  be  viewed  and  modified  by 
processes  operating  at  different  security  levels*  Data  is  security 
relevant  if  it  contains  global  information  which  traverses  several  secu¬ 
rity  levels* 

Under  this  definition*  a  considerable  amount  of  CP  code  is  security 
relevant  because  it  makes  wide  use  of  global  system  tables*  Many  of 
these  tables  can  be  distributed  so  that  each  copy  contains  only  data 
relevant  to  a  uniaue  security  level*  The  code  manipulating  these  dis¬ 
tributed  tables  can  then  be  made  reentrant  so  that  most  of  the  code 
loses  its  security  relevance  (however*  privileged  instructions  would 
still  be  security  relevant)* 

Our  approach  was  thus  driven  by  identifying  non-security  relevant  code 
in  CP  and  virtualizing  it  out  of  the  privileged  execution  domain*  The 
non-vi rtual ized  portion*  plus  additional  security  enforcement  code* 
became  the  Kernel*  One  can  become  tempted  to  virtualize  almost  every¬ 
thing  out  of  the  Kernel  since  the  more  code  that  is  virtualized*  the 
less  there  is  to  verify*  However*  since  the  purpose  of  global  system 
tables  is  the  efficient  management  of  the  real  machine*  the  wholesale 
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partitioning  of  this  information  would  causa  system  efficiency  to 
degrade  as  coda  is  virtualizad  out  of  tha  Karnal  and  Global  Process 
domains* 

Conseouentlw *  considerable  attention  had  to  be  paid  to  tha  characteris¬ 
tics  of  KVM's  expected  use  environment  in  order  for  us  to  identify  those 
functions  that  would  have  to  share  global  data  in  order  for  us  to  attain 
reasonable  system  performance  efficiency*  Our  analysis  was  based  on  the 
assumption  that  typically  KVM  would  concurrently  support  a  moderate 
number  of  security  levels  (approximately  five)*  and  that  each  level 
would  support  essentially  the  same  number  of  virtual  machines*  Ue  ana¬ 
lyzed  a  number  of  alternatives  for  each  form  of  inter-component  communi¬ 
cation  on  the  basis  of  security  characteristics*  performance  impact*  and 
difficulty  of  implementation*  The  resulting  design  and  implementation 
are  such  that  an  installation's  deviation  from  these  assumptions  could 
significantly  alter  the  performance  characteristics  of  KVM* 

3*4  System  Verification 

Formal  verification  of  Kernel  and  Trusted  Processes  at  the  specifi¬ 
cation  level  will  demonstrate  that  these  functions  be  shown  to  correctly 
implement  the  sharing  policy  between  subjects  and  objects  in  terms  of 
the  basic  security  principle  and  the  Confinement  Property. 

This  form  of  proof  involves  demonstrating  that  all  system  state  transi¬ 
tions  preserve  a  set  of  security  invariants*  The  proof  of  correctness 
will  be  achieved  with  the  assistance  of  an  interactive  theorem  prover 
(ITP)  which  is  used  to  produce  a  fully  annotated  formal  proof  that  the 


21 


state  transitions  of  the  Kernel  and  Trusted  Processes  preserve  the 


invariance  of  the  KVM  correctness  criteria. <14>  Foreal  verification  of 
the  KVM/370  specif ications  is  in  prodress*  and  should  conclude  in  earls 
1982*  Verification  activity  had  been  postponed  until  October  1979 
because  of  fundind  anoealies.  Conseouently *  the  KVM  formal  specifica¬ 
tions  have  been  rewritten  into  abstract  top-level  specifications  and 
more  concrete  refined  specif ications  in  order  to  facilitate  the  tasks  of 
provind  the*  and  of  demonstrated  their  correspondence  to  the  JOVIAL 
implementation .  The  two  levels  of  formal  specifications  are  ridourousls 
linked  with  Ina  Jo  mappinds.  The  top-level  specifications  were  formally 
verified  as  of  October  1980.  The  second-level  specifications  will  be 
submitted  to  the  formal  verification  process  in  1981-1982. 

3.3  Possibility  of  Hardware  Error* 

The  project  staff  was  concerned  over  the  possibility  of  violations  of 
the  security  policy  occurrind  because  of  failure  of  the  hardware  securi¬ 
ty  controls.  Some  possibilities  considered  were! 

»  failure  of  the  rrivileded  operation  protection  mech¬ 
anism* 

*  an  error  in  address  translation  or  the  Translation 
Lookaside  Buffer  <TLB)» 

*  failure  of  the  storade  protection  mechanism* 


<14> 

The  ITP  is  one  of  the  tools  used  in  SDC's  Formal  Development  Meth- 
odolody.  The  theorems  proved  by  the  ITP  are  denerated  automatically 
from  the  Ina  Jo  specifications  by  a  mechanical  Specification  Processor. 
The  theorems  are  derived  aldorithmically  from  the  Correctness  Criteria* 
Invariants*  Constraints  and  Mappinds  used  in  Ina  Jo  specifications. 
Full  ridour  is  maintained  throudhout  this  process. 
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*  misinterpretation  of  a  CCU  by  a  channel? 

t  an  I/O  device  responding  to  the  wrong  device 
address) 

*  mishandling  of  a  comeand  by  an  I/O  device* 

Each  of  these  possibilities  was  considered  in  depths  and  where  appropri¬ 
ate*  KVH  addresses  the  problems  through  a  combination  of  architectural 
and  procedural  (administrative)  measures.  The  interested  reader  is 
referred  to  C173  for  a  discussion  of  these  problems  and  their  resolu¬ 
tion* 

3*6  Elimination  of  Known  Security  Flaws 

There  are  about  30  security  flaws  known  in  Release  3*0  of  the  commercial 
version  of  VH/370.  A  hardened  version  could  be  produced  by  fixins  these 
errors*  but  there  misht  be  other  errors  which  had  not  b*en  detected  and 
the  fixes  misht  themselves  introduce  new  security  flaws.  KVM/370  aoes 
further  and  eliminates  both  known  and  unknown  security  flaws*  It  is 
instructive*  however*  to  see  how  the  presence  of  a  security  Kernel  and 
the  constraints  it  places  on  the  system  desisn  eliminate  some  of  these 
errors. 

Almost  every  security  flaw  in  the  VM/370  system  involves  the 
inrut/outrut  f unctionsCll .  Since  there  is  no  address  space  validation 
of  input/output  by  the  hardware*  other  than  that  performed  by  the 
storage  protection  keys*  VM/370  must  validity-check  all  channel 
programs  and  relocate  all  virtual  addresses*  including  both  main  storage 
addresses*  and  DASD  cylinder  addresses  in  seek  arguments  and  home 
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addresses*  The  saee  I/O  Iodic  is  repeated  for  several  different 
reauirementsi  virtual  spooling  support*  virtual  console  support*  vir¬ 
tual  channe-l-to-channel  adapter  support*  and  a  special  VH/370  I/O 
interface*  Each  variation  of  this  support  eeans  that  errors  maw  be 
present . 

These  errors  occur  in  the  translation  of  channel  programs  as  a  result  of 
the  complexity  of  the  channel  coeeand  language*  For  example*  the  saee 
word  in  a  channel  program  might  be  used  as  a  coeeand  or  as  an  operand 
address  depending  upon  the  execution  seauence  of  the  prodraeCl]* 
Since  the  System/370  architecture  allows  *puns*  in  the  channel*  in  that 
a  word's  interpretation  depends  on  whether  it  is  received  as  the  leading 
or  trailing  portion  of  a  land  coeeand*  it  is  possible  to  bwpass 
checkins  in  these  eodules  and  access  DASD  records  C13. 

Under  KVM/370*  channel  coeeand  words  are  not  pereitted  to  take  on  dif¬ 
ferent  eeaninds  depending  on  the  seauence  of  execution*  Primarily*  this 
means  that  an  NKCP  cannot  submit  certain  channel  commands  with  transfers 
or  with  certain  modifier  bits  set*  This  does  not  preclude  users  (UMs> 
from  constructing  such  channel  programs*  it  merely  reauires  the  NKCP  to 
put  them  into  a  standard  form  before  submitting  them  to  the  Kernel* 
Further*  these  commands  will  be  copied  into  the  Kernel's  data  space  and 
translated  and  modified  there*  preventing  their  modification  by  an  NKCP 
between  the  time  of  translation  and  time  of  execution*  Also*  self¬ 
modifying  channel  programs  such  as  those  used  by  QS/360  ISAM*  will  not 
be  permitted*  since  doing  so  would  permit  bypassing  the  Kernel's  refer¬ 
ence  monitor  function  and  open  the  system  to  the  possibility  of  penetra- 


Certain  VM/370 


penet  rationed! 


dependent 


upon 


simultaneous 


input/output  and  CPU  execution  are  beins  countered  bw  removins  froa  the 
address  space  of  the  reauestor  all  pases  which  are  buffering  input. 
This  applies  to  both  NKCP  and  user  VMs.  In  the  event  either  NKCP  or  a 
UH  needs  access  to  such  a  rase,  its  execution  will  be  delawed  until  the 
1/0  completes  and  the  pass  is  made  available.  For  example*  under 
VM/370*  careful'  tiains  of  aswnchronous  execution  could  be  used  to 
exploit  a  bizarre  oversight  in  condition-code  checkins  to  sain  a  total 
swstem  penetration  (real  supervisor  state)C13* 

Althoush  the  treatment  of  storaSe  and  tiains  channelsC83  is  bewond  the 
scops  of  a  swstem  such  as  VM/370*  thew  must  be  controlled  in  a  militarw 
swstem  such  as  KVM/370.  In  this  respect*  we  have  thoroushlw  audited 
all  Global  Processes  that  allocate  and  schedule  resources  amons  VMs  at 
different  levels  for  TroJan  Horses.  Hence*  it  will  not  be  possible 
to  transmit  information  over  a  covert  communication  channel  at  a  hish 
enoush  bandwidth  to  make  such  attempts  worthwhile. 

4.0  CURRENT  STATUS  AND  PLANS 

4.1  Recent  KVN  Status  and  Thrusts 

The  Fiscal  Year  1781  taskins  for  KVM  was  directed  in  the  two  following 
general  areas: 

I.  Preparation  of  the  KVM/370-Alpha  Release 
II.  Installation*  Demonstration  and  Measurement  of  the 
KVM/370- Alpha  Release 
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In  October*  19^9'  KVH  development  reached  an  important  and  significant 
milestone*  A  demonstration  was  Siven  of  a  development  version  of  KVH 
system  consisting  of  three  distinct  address  spaces'  (the  Kernel  and  two 
NKCPs)  which  was  able  to  support  the  address  spaces  and  functional 
retirements  of  two  users  at  two  security  levels*  The  basic  architec¬ 
tural  design  of  the  system  had  been  proven  feasible  at  that  point.  One 
fifth  of  the  control  program  (20*000  assembly  language  instructions  dis¬ 
tributed  throughout  the  120*000  lines  of  original  CP)  had  been  signifi¬ 
cantly  altered*  and  this  successfully  makes  service  calls  to  a  security 
Kernel  consisting  of  3000  JOVIAL  statements*  This  represented  a  major 
architectural  accomplishment  and  presented  a  solid  foundation  for  the 
addition  of  more  functionality  to  the  system* 

Two  major  milestones  were  achieved  at  that  timet 

(1)  The  Kernel  supported  one  NKCP  and  two  interactive 
virtual  machines  (VHs)t  and 

(2)  The  Kernel  concurrently  supported  two  NKCPs  (i*e.» 
two  distinct  pseudo-classif ied  security  levels)  each 
with  one  active  VH. 

Two  major  test  versions  of  KVM/370  were  subseouently  constructed  and 
tested  successfully*  each  KVH  version  capable  of  supporting  two  users  at 
the  same  level  and  two  users  at  different  levels.  The  levels  were 
designated  'High*  and  'Low*.  Each  user  was  able  to  exercise  most  of  the 
control  program  (CP)  commands*  viz  LOGON*  LOGOFF*  QUERY*  HESSAGE*  SLEEP* 
BEGIN*  DUHP*  SET*  LINK*  IPL*  etc.  In  addition*  he  could  perform  simple 
CHS  edit  commands*  using  the  created  edit  file  for  assemblies*  etc.  As 
expected*  CHS  commands  that  involve  input/output  seauences  (e.s.*  IPL) 
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were  executing  an  order  of  magnitude  aort  slowly  than  thaw  do  in  tha 


standard*  tuned*  VM/370  ralaasa*  This  performance  dasradation  was  a 
temporary  rasult  of  radundant  NKCP  rasa  calls  to  tha  Kernel*  VM/370 
overhead*<13>  and  a  faw  Karnal  calls  (JOVIAL)  that  taka  savaral  milli- 
saconds  to  complete*  A  portion  of  tha  KVM  affort  sinca  than  has  baan 
davotad  to  improving  swstaa  performance  bw  a  coabination  of  performance 
measuraaant  and  tuning* 


As  of  November  1980*  whan  tha  project  had  transitionad  to  RADC*  tha  work 
on  tha  prototype  KVM/370  swstaa  had  raachad  tha  point  whera  it  is 
possibla  to  daaonstrata  tha  capability  of  concurrently  supporting  siaple 
virtual  aachinas  at  aach  of  two  psaudo-classif iad  security  levels* 
coaplete  with  paging  support* 

The  aaJor  thrust  for  tha  project  sinca  October  of  1979  has  baan  tha 
saturation  of  KVM/370  into  a  viable  aulti-leval  secure  system*  The  pro¬ 
ject  resuaed  support  for  an  effort  to  obtain  KVN's  certification  and  ac- 


<15> 

Tha  current  test  version  is  being  supported  by  VM/370*  As  such*  it 
is  being  run  interactively  by  VM/370-CP*  Hence*  the  swstaa  is  cur¬ 
rently  undergoing  two  levels  of  paging*  and  all  privileged  operations 
are  being  simulated  bw  both  VM/370-CP  and  bw  tha  KVM  Kernel*  By  Novea- 
ber  1980*  however*  tha  VM/370  support  for  tha  test  anvironaent  was  tem¬ 
porarily  eliminated  whan  KVM  was  successfully  installed  on  SDC's  IBM 
4331  computer.  A  preliminary  version  of  KVM-AlPha  was  demonstrated  on 
tha  bare  4331  in  October  1980*  As  trusted  Cnon-psseable]  coda  was  added 
to  tha  swstaa*  however*  tha  developing  KVM-Alpha  prototype  grew  larger 
than  tha  available  memory  of  tha  4331*  A  replacement  upgrade  to  an  IBM 
4331-11  was  ordered* 

Tha  system  development  process  progressed  far  more  rapidly  on  the  4331 
than  had  been  the  case  with  the  remotelv-sccessed  computers  used  in  the 
past*  It  is  expected  that  information  gained  from  installations  at  the 
planned  Alpha-  and  Beta-test  sites  will  further  improve  the  testing* 
analysis  and  development  of  the  full  system. 


eradication  for  multi-level  site-srecif ic  applications*  In  ordar  that 
KVM/370  ba  cartifiad  for  use  in  multi-level  security  applications*  tha 
Qovarnaant  raauiras  avidanca  that  KVH  correctly  anforcas  DoO  sacuritw 
policy  ovar  its  usars  and  thair  processes*  Although  cartif itation 
activities  will  involva  significant  testing*  panatration  analwsas  and 
docuaantation  reviews*  currant  DoD  cartif ication  trands  raauira  foraal 
avidanca  of  tha  security-worthiness  of  candidata  systems*  This  is 
bacausa  no  faasibla  aaount  of  testing  can  produce  conclusive  avidanca  of 
the  absence  of  security  flaws  froa  a  system*  even  thoush  such  testing 
•ay  uncover  no  such  flaws* 

Tha  DoD  has  begun  to  raauira  that  all  candidata  swstaas  ba  presented  for 
thair  review  complete  with  foraal  swstaa  specifications  written  in  a 
non-procedural  logically  complete  predicate-calculus  based  specification 
language*  along  with  formal  proofs  that  tha  specifications  are  complete 
and  consistent  with  respect  to  enforcement  of  DoD  security  policy* 
Foraal  models  of  DoD  sacuritw  policy  have  bean  expressed  as  swstaa- 
srecific  interpretations  of  tha  LaPadula  and  Ball  modal  of  security 
produced  by  the  MITRE  Corporation.  C9*  103 

Tha  KVM/370  project  originally  produced  an  unverified  single-level 
abstract  foraal  specification  of  the  KVH  Kernel  and  Trusted  Procassas  in 
tha  1978  dialect  of  SDC's  foraal  specification  language  Ina  Jo*  along 
with  a  foraal  statement  of  tha  Security  Condition  that  is  to  ba  pre¬ 
served  as  an  invariant  by  tha  Kernel  and  Trusted  Processes* 
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Under  the  direction  of  DARPA*  the  foreal  KVM  specifications  were  written 
as  foreal  implementation-level  specifications*  Conseauently *  the  foreel 
specifications  for  KVM  were  not  in  a  fore  that  would  pereit  their  foreal 
verification  us  ins  the  foreal  verification  tools  in  SDC's  trusted  soft-* 
ware  Foreal  Oevelopeent  Methodology  <FDM)«<16> 

Since  the  start  of  Fiscal  Year  L981 >  SOC  has  eodified  the  KVM  foreal 
specif ications  to  confore  with  the  evolving  reauireeents  of  the  FDM.  In 
October*  1980*  proofs  were  produced  of  the  new  TLS*  Foreal  verification 
of  the  SLS  will  begin  in  Maw  1982  under  a  KVM-Beta  Release  developeent 
contract. 


4.2  Summary  of  Progress  at  RAOC 

Prior  to  the  start  of  the  KVM  Technical  Deeonstration  effort*  the  pro¬ 
ject  plan  was  carefullw  reviewed  and  a  new  developeent  schedule  was 
developed.  The  coding  schedule  showed  an  orderly  progression  of  ‘coding 
rounds*  that  would  lead  to  the  KVM-Alpha  and  KVM-Beta  Releases*  with 
well-defined  intereediate  increeental  system  releases. 


<16> 

FDM  reauires  that  foreal  specifications  originate  froe  a  highly 
abstract  Top  Level  Specification  (TLS)  which  is  foreally  proven  to 
satisfy  a  Criterion  for  Correctness.  Following  verification  of  the  TLS* 
the  TLS  is  refined  into  a  more  concrete  Second  Level  Specif ication 
(SLS).  Foreal  correspondences  (mappings)  are  produced  between  the 
abstract  TLS  objects  and  the  more  concrete  objects  of  the  SLS.  Foreal 
proof  evidence  is  then  produced  to  deeonstrate  that  the  SLS  is  a  faith¬ 
ful  and  correct  implementation  of  the  TLS  vis-a-vis  the  Security  Condi¬ 
tion*  That  is*  the  EFFECTS  section  of  each  SLS  state  transition  is 
shown  to  imply  the  EFFECTS  section  of  each  TLS  state  transition.  Upon 
completion  of  this  proof*  transitivity  of  implication  yields  the  proof 
that  the  SLS  preserves  the  Criterion  for  Correctness. 
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Detailed  functional  descriptions  of  the  Kernel  and  Trusted  Process  in¬ 


ternals  were  also  initiated  during  this  time  period* 

Under  RADC  contract  management*  coding  proceeded  according  to  the 
revised  schedule*  and  bv  mid-March  the  prototype  KVM-Alrha  Release  was 
in  final  testing* 

4.2.1  KVM  Alpha  Test  Site  at  NATC 

In  the  Spring  of  1981*  a  test  version  of  KVM  was  delivered  to  the 
government.  This  version  of  KVM  is  called  *KVM  Alpha*. 

KVM  Alpha  is  a  running  prototype  of  the  eventual  *full  KVM*  systea.  It 
offers  aost  of  the  functionality  of  Release  3  PLC  13  of  VM/370*  the  not¬ 
able  exceptions  being  no  support  for  virtual-virtual  operating  systeas 
and  no  secure  accounting  process.  The  Authorization  process  and  the 
Updater  process  offer  rudiaentarv  support  for  the  proper  separation  of 
security  levels  and  virtual  aachines* <17>  but  is  not  readily  aaenable  to 


<17> 

The  function  of  the  Updater  process  is  to  aaintain  the  integrity  of 
the  security  profile  directories  of  users*  virtual  aachines*  and  peri¬ 
pheral  devices  as  they  are  updated  by  the  systea  security  officer.  Soae 
of  these  updates  are  reflected  iaaediately  in  the  user's  directory* 
whilst  others  are  delayed  until  the  user  does  not  have  an  active  process 
on  the  systea.  The  data  bases  built  and  aaintained  by  the  Updater  are 
used  by  the  Authorization  process  <snd  its  Initiator  coaponent)  as  the 
fundamental  aeans  of  interpreting  security  policy  for  all  active 
subjects  and  objects  in  the  system.  In  effect*  the  Authorization  pro¬ 
cess  must  act  as  a  saall  multi-level  data  base  management  system  that 
implements  appropriate  views  of  user  directories  for  the  KVM  Kernel* 
Trusted  Processes  and  NKCPs.  These  views  are  derived  from  a  set  of 
Third  Normal  Form  relational  data  bases*  through  a  filter  which  inter¬ 
prets  DoD  security  policy  under  a  model  similar  to  the  MITRE  security 
policy  model.  The  Updater  process  provides  the  data  base  generation* 
maintenance*  and  update/recovery  functions*  and  has  responsibility  for 
overall  preservation  of  data  base  integrity  for  KVM.  Since  the  data 


ra^id  Modification  of  user  directories*  nor  does  it  support  protected 
special-access  passwords  or  the  construction  of  audit  trails*  Dial-up 
access  is  not  supported  in  KVM  Alpha* 

Essentially*  KVH  Alpha  will  be  a  basic  test  vehicle  for  performance 
measurement  and  user  evaluation/f amiliarization*  New  features  will  be 
incorporated  into  KVH  Alpha  throughout  FY81  and  into  FY82*  until  the 
Summer  1982  release  of  the  complete  system* 

KVH  Alpha  was  installed  at  the  Naval  Air  Test  Center*  Patuxent  River* 
Maryland*  between  29  March  and  10  April  1981* 

4*2*2  Experiences  During  the  NATC  Installation  of  KVM-Aleha 

The  month  of  April  marked  the  successful  installation  of  the  KVM-Alpha 
prototype  at  the  Naval  Air  Test  Center*  Patuxent  River*  Maryland*  The 
installation  was  performed  over  the  Period  29  March  throush  10  April  by 
a  team  consisting  of  Dick  Linde*  Pat  Ward*  Guy  Schroeder  and  Marvin 
Schaefer  at  NATO  with  contemporaneous  support  provided  by  Robin  Peeler 
and  Marty  Massoslia  at  SOC  in  Santa  Monica* 

SDC  would  like  to  acknowledge  the  high  level  of  support  given  to  the 
project  by  Mr.  Gordon  Fullerton  and  Mr*  Danny  Weddel  of  NATC  during  the 
two  weeks  of  the  installation.  NATC  provided  the  KVM  project  with  third 
shift  dedicated  computer  time  on  weekdays?  additional  shift  hours  were 

base  management  functionality  of  the  Authorization  process  is  conceptu¬ 
ally  much  simpler  than  that  of  the  Updater*  the  initial  release  of  KVM 
Alpha  does  not  provide  Updater  facilities  directly*  Rather*  the  KVM 
Directory  is  manually  prepared  and  compiled  directly  into  the  release 
for  each  test  site* 


provided  on  29  March  and  on  4  April*  Because  of  installation  difficul¬ 
ties  encountered  at  NATC*  RADC  postponed  the  installation  of  KVM-Alpha 
at  the  designated  Army  Coeeunications  Asency  test  site  to  soee  future 
date* 

The  KVM-Alpha  installation  at  NATC  was  plasued  with  unanticipated  tech¬ 
nical  difficulties*  A  majority  of  the  problees  were  related  to  incompa- 
tibilities  between  SDC's  IBM  4331  system  environeent  (hardware*  software 
and  conf isuration)  and  NATO's  AMDAHL  V7A  system  environeent*  Other 
naJor  problees  arose  in  the  areas  of  the  IBM  8809  Tape  Drive*  and  the 
KVM  Director*  Macros*  These  are  discussed  below* 

The  installation  teae  carried  two  coaplete  4-tame  backups  of  the  KVM- 
Alpha  system  to  NATC*  includins  source  code*  the  loadable  (under  VM/370- 
CP)  4331  conf isuration*  docueentation*  editors*  etc*  Mr.  Fullerton  pro¬ 
vided  the  staff  with  disk  space*  user  IDs*  and  revised  conf isuration 
data*  Repeated  atteepts  failed  to  restore  our  files  froe  the  backup 
tapes  usins  either  the  IBM  proSraa  YMFPLC2  or  the  University  of  Waterloo 
PETAPE  utility*  Analysis  of  tape  dumps  (made  by  Mr*  Fullerton  with  MVS 
utilities)  confirmed  that  the  tapes  were  compatible  with  the  NATC  tape 
drives<18>  and  were  produced  under  SDC's  version  of  PETAPE.  It  was  then 
determined  that  NATC  was  usins  an  older*  incompatible*  release  of 
PETAPE* 


<18> 

For  a  while  it  was  suspected  that  they  misht  have  been  senerated  in 
data-st reamins  mode  by  the  IBM  8809*  in  which  case  new  backup  tapes 
would  have  had  to  be  created  and  shipped  from  SDC* 
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A  new  taps  was  constructed  at  SDC*  usins  standard  IBH  utilities*  con¬ 
taining  PETAPE  and  soee  key  modules.  The  tape  was  air  freishted  to 
NATC*  but  was  not  received  for  three  daws*  Meanwhile*  Guw  Schroeder 
decrypted  the  PETAPE  formattin*  code  (undocueented)  and  reconstructed 
PETAPE  from  our  backup  tapes*  usins  Hr.  Fullerton's  knowledge  of  the  MVS 
tape  duep  utilities*  Once  this  was  done*  it  was  possible  to  retrieve 
the  files  from  ‘  the  backup  tapes*  Unfortunately*  two  nishts  were  lost 
because  of  this  problem* 

It  was  subseouentlw  discovered  that  soee  of  the  files  on  the  backup 
tapes  had  not  been  copied  successfully  froe  the  3370  disk*  The  problea* 
identical  on  both  sets  of  backup  tapes*  involved  several  consecutive 
file  pairs:  in  each  pair*  the  two  files  were  written  contiguously  such 
that  the  last  part  of  the  first  file  end  the  first  part  of  the  second 
file  of  each  pair  were  eissins*  Not  all  of  the  daaased  files  were 
essential  to  the  KVM-AlPho  installation*  soee  of  the  daeaae  was  to 
source  code*  soee  was  to  object  code*  soee  was  to  utilities*  New  tapes 
were  shipped  to  NATC  containins  the  most  essential  eodules*  includins 
the  JOVIAL  compiler*  As  file-damase  was  discovered  in  other  essential 
files*  the  eissins  data  was  recovered  as  hard-copy  listinSs  obtained 
throuSh  a  300-baud  remote  dial-up  to  the  SOC  4331  in  Santa  Monica.  (The 
SDC  4331  is  remotely  accessible  via  TYMNET  and  Dial-Up  lines*)  The 
missins  data  was  then  manually  typed  into  files  on  the  NATC  machine  and 
incorporated  into  the  system*  <In  most  but  not  all  cases*  this  reeuired 
typins  in  less  than  100  lines  of  JOVIAL  or  assembly  lansuase*) 
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One*  the  KVM-Alpha  swstem  was  restored*  an  attempt  was  made  to  load  it 
undar  VM/370  for  preliminarv  testina  undar  tha  NATO  conf iduration.  Spu¬ 
rious  arror  messades  wara  racaivad  on  tha  AMDAHL  console*  and  tha  swstem 
crashad  rereatedlw  and  nondeterministicallw  whila  KVM  was  baina  IPLad  or 
shortlw  aftar  tha  IPL  saouanca  ended.  Most  of  tha  arrors  indicated 
rrobleas  in  an  I/O  Control  Unit*  Attempts  to  isolate  tha  arror  failed* 
Tha  NATC  VM  swstem  failed  onl*  whan  attempts  wara  made  to  run  KVM  undar 
it* 

Gu*  Schroeder  learned  from  other  AMDAHL  users  that  there  is  a  known*  but 
relatival*  undocumented*  bud  in  tha  AMDAHL  architecture  that  prohibits 
runnina  a  2K  virtual  padind  swstem  <e*d**  KVM*  DOS/VS*  ate.)  undar  a  4K 
virtual  swstem  (a.d.*  VM/370*  MVS*  etc.)*  Tha  suddestad  resolution  to 
the  problem  involved  *cuttind*  cache  memorw  in  half*  a  modification 
(dona  from  tha  operator's  console)  that  several*  impacts  AMDAHL  perform¬ 
ance.  Tha  modification  was  made  and*  on  tha  fourth  nidht*  it  was  first 
possible  to  brind  tha  test  svstem  up  under  VM/370  on  tha  modified 
machine . 

Tha  NATC  conf iduration  had  chanded  somewhat  b*  tha  time  tha  installation 
team  arrived  at  NATC.  In  order  to  represent  tha  new  conf iduration*  it 
was  nacassar*  to  construct  a  new  KVM  Director*  with  tha  Macros  that  had 
bean  written  as  tamporar*  tools  for  this  purpose. 

Several  problems  wara  encountered  in  implemented  tha  revised  director** 
primaril*  due  to  tha  complexity  of  tha  macros.  Tha  maJorit*  of  these 
problems  ware  overcome.  Each  attempt*  however*  reouirad  a  recompilation 
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of  several  KVM  modules*  sine*  the  System  Security  Officer  functionality 
of  the  Updater  Process  is  not  schadulad  for  iaplementation  for  savarsl 
•onths. 

It  was  found  that  undar  KVM »  usars  aust  have  a  writabla  A-Disk  at  aach 
security  laval  at  which  thaw  intend  to  use  CMS.  This  reauired  the  crea¬ 
tion  of  a  large  nuabar  of  A-Disks  for  tha  user  IDs  for  which  wa  had  con¬ 
figured  tha  swstaa.  (A  user  cleared  to  TS *  havins  two  catasorias  in  his 
clearance*  could  raouire  as  aany  as  16  distinct  A-Disks  in  order  to 
operate  at  all  of  his  potential  security  levels.) 

4.2.3  NATO  System  Perforaanca  Test 

Tha  KVM-Alpha  swstaa  prototype  was  successfully  IPLed  and  executed  on 
tha  bare  NATC  AMDAHL  V7A  on  Friday  morning*  10  April  1981.  "  It  was 
possible  to  run  one  limited  perforaanca  benchaark  test  prior  to  releas¬ 
ing  the  aachina  for  NATO's  noraal  daily  operation.  This  test  involved 
the  running  of  a  JOVIAL  coapilation  of  several  KVM  Kernel  modules.  The 
compilation  was  run  first  under  VM/370-CMS  in  stand-alone  mode*  it  was 
then  run  in  stand-alone  mode  under  KVM-CMS  on  the  bare  AMDAHL  V7A.  The 
test  results  were  (in  wall-clock  time),  under  VM/370  —  two  minutes*  11 
seconds)  under  KVM/370  —  four  minutes*  21  seconds.  The  compilation 
was  I/O  bound*  the  testcase  included  a  combination  of  100  syntactic  and 
semantic  JOVIAL  errors. 

Earlier*  during  the  second  week  of  the  KVM-Alpha  installation*  Susan 
RaJunas  (MITRE)  tested  the  system  Execs  for  NATO's  PL/I  coapiler. 
Unfortunately*  during  the  period  of  her  visit  KVM-Alpha  could  not  yet  be 


executed  on  the  bare  V7A  because  of  hardware-specific  problems  in  the 


KVM  IPL  seauence*  These  problems  were  not  resolved  until  she  and  HaJor 
Darr  had  returned  to  their  organizations*  The  PL/I  test  cases  could  not 
be  run  because  documentation  for  the  use  of  the  PL/I  compiler  was  un¬ 
available  at  the  time  of  the  tests* 


It  had  originally,  been  intended  to  run  at  least  the  following  perform¬ 
ance  tests*  a  common  Job  with  one  user?  two  users  on  the  same  NKCP*  and 
two  users  on  two  separate  NKCPs*  then  a  mix  of  Jobs  on  one  NKCP*  and 
then  on  two  NKCPs*  and  finally*  the  above  on  the  machine  with  different 
amounts  of  memory  available  (in  order  to  force  paging  activity)*  How¬ 
ever*  KVH-Alpha  did  not  reach  a  demonstrable  state  until  a  few  hours 
before  the  end  of  the  final  run  on  the  NATO  computer*  In  final  prepara¬ 
tion  for  the  performance  tests*  the  installation  team  encountered  timing 
problems  with  the  TELEX  IBH  3278-compatible  terminals*  The  Directory 
also  had  to  be  modified  when  it  was  discovered  that  some  line  addresses 
improperly  designated  3278  eouivalent  terminals  as  3277s*<19> 


Preparations  had  been  completed  for  the  demonstration  of  KVM-Alpha  and 
the  training  classes  that  were  to  have  been  given  to  the  NATC  operators 
and  users.  Hr.  Fullerton  was  shown  how  to  IPL  the  Alpha  system*  and  was 


<19> 

Of  the  two  3277s  in  the  machine  room*  it  was  not  possible  to  use 
one  for  testing  an  assembly  concurrent  with  the  compilation  because  the 
Directory  defined  the  minimum  pseudo-security  level  of  both  terminals  as 
higher  than  the  security  level  of  the  A-Disks  (and  clearance)  of  the 
user  with  access  to  the  assembler*  There  was  not  sufficient  time  to  re¬ 
compile  the  Directory  to  run  this  test*  We  believe  that  it  would  have 
been  possible  to  run  a  more  statistically  meaningful  set  of  performance 
benchmarks  had  the  team  been  able  to  obtain  access  to  the  AMDAHL  for  one 
more  shift* 
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present  for  soae  of  the  testins  under  VH/370.  HaJor  Oarr  loaded  into 
KVH-Alpha  under  VH/370*  and  entered  a  few  CHS  coaaands.  HaJor  Darr  and 
Hs.  RaJunas  were  diven  conies  of  the  Operator's  and  Users'  Quids  for 
KVH-Alpha*  and  of  the  visuals  that  had  been  prepared  for  the  trainind 
class  and  deaonstration.  Other  than  this  liaited  exerciser  no  deaon- 
strations  or  trainind  were  perforaed. 

Since  KVH-Alpha  exceeds  the  aeaorw  size  of  the  4331-1  *  and  because  of 
the  project's  continuind  need  for  the  4331-1  as  a  support  aachine*  it 
was  not  possible  to  perfore  bare  aachine  perforaance  tests  on  KVH-Alpha 
at  SDC.  Additional  perforaance  tastind  is  planned  for  a  return  visit  to 
the  NATC  test  site*  and  for  the  SDC  4331-11  in  future  aonths* 

4.3  KVH  Plans 

Since  its  initiation  in  1976*  the  priaarw  doal  of  the  KVH  project  has 
been  to  produce  a  certified  aulti-level  secure  swstee  that  is  essenti¬ 
ally  coapatible  with  the  coaaerciallw  available  IBH  VH/370  svstea.  This 
coapatibilitw  would  perait  KVH's  user  coaaunitw  to  install  their  exist- 
ind  370  applications  with  ainiaal  aodif ication. 

KVH  developaent  has  reached  the  point  where  it  is  appropriate  to  address 

the  reeuireaents  of  its  potential  user  coaaunitw.  Over  the  next  one  and 

a  half  wears*  the  svstea  will  be  subaitted  to  a  selected  user  aroup  that 

will  participate  in  its  earlw  tastind  and  evaluation.  In  the  Suaaer  of 

1982*  KVH  should  reach  the  point  where  it  can  be  subaitted  to  the 

dovernaent*  alona  with  substantiated  foraal  docuaentation*  for  aulti- 

level  certif ication  consideration. 
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In  Fiscal  Year  1982.  the  KVM  prototype  will  be  matured  from  a  tast  envi- 
ronaant  into  an  operational  environment.  that  can  ba  supported  by  a 
coareti tivelw  selected  system  aaintananca  organization . 

4.3.1  KVM  Alpha  Tast  Sites 

Currently.  it  is  planned  that  a  second  visit  be  aade  to  the  NATC  Alpha 
test  site  to  install  an  updated  and  corrected  version  of  KVM-Alrha.  At 
that  tine.  extensive  performance  benchnarkins  and  aeasureaent  activities 
will  be  conducted.  The  second  visit  will  conclude  with  a  demonstration 
of  the  KVM-Alrhe  release  to  NATC  site  personnel. 

4.3.2  July  1982  KVM  Beta  Release 

In  Julw  1982*  KVM  will  have  been  tested  and  tuned  durins  a  wear  of  user 
evaluation.  Concurrent  with  its  testins.  additional  features  will  be 
added  to  the  implementation  so  that  the  resultins  version.  'KVM  Beta*, 
is  functionallw  consistent  with  all  of  the  VM/370  Release  3  PLC  IS  fea¬ 
tures  it  was  intended  to  support. 

Durins  the  testins  period,  the  evaluators  of  KVM  Alpha  maw  identify 
system  ' rouSh  edses'i  ouirks  that  make  KVM  Alpha  difficult  to  use.  The 
KVM  implementation  team  will  analyze  the  nature  of  these  ouirks  and. 
where  consistent  with  budeet.  schedule  and  security  constraints,  make 
appropriate  modifications  to  the  KVM  user/security-officer  interface. 
KVM  Beta,  the  system  evolved  from  this  crucible  of  testins  and  evalua¬ 
tion.  should  be  a  more  practical  system  than  its  predecessor* 
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Any  known  security  def iciencies*  either  those  indicated  free  the  foreel 


specification  verification  effort*  or  those  indicated  by  the  user  com¬ 
munity*  will  have  been  analyzed  and  resolved*  These  security  deficien¬ 
cies  tay  be  of  several  types*  These  are*  situations  in  which  the  speci¬ 
fication  cannot  be  verified  without  aodif ication)<20>  situations  in 
which  foreal  analysis  of  the  specifications  uncovers  an  actual  security 
desisn  flaw*<21>  and  those  in  which  a  codins  error  is  discovered 
throush  testinS*  The  latter  can  occur  because  of  the  fact  that  the  code 
is  not  beins  formally  verified  for  its  consistency  with  respect  to  the 
foreal  specifications* 

KVM  Beta*  then*  will  be  a  tuned  systee  which*  to  the  best  of  our  know- 
ledSe*  is  a  coerlete  and  certifiably  secure  inpleaentation  of  KVM* 
tested  by  outside  users  as  well  as  its  iarleaentors*  and  in  reasonable 
correspondence  with  its  verified  foreal  specifications.  However*  the 
tasks  described  in  Parasraph  4*3*4*  below*  will  be  reauired  in  order  to 
aore  foraallw  deaonstrate  the  correspondence  between  specification  and 
implementation. 


<20> 

This  condition  can  arise  as  a  conseeuence  of  current  liaitations  in 
the  verification  technology*  and  has  no  relationship  to  the  security 
properties  of  the  underlying  svstea*  Of  course*  aodif ications  to  the 
specification  would  have  a  corresponding  impact  on  the  iapleaentation. 

<21> 

Here*  the  specifications  would  have  to  be  aodified  and  reverified* 
and  the  implementation  correspondingly  modified* 
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4.3*3  Formal  Documentation  for  Certification 


In  order  to  support  the  detailed  laboratory  analysis  reouired  for  KVH 
certif ication»  we  will  annotate  the  foreal  KVH  specifications  so  that 
the  evaluators  can  understand  the  security  model  and  the  abstractions 
used  in  the  specifications.  This  annotation  will  be  provided  in  the 
fcrm  of  an  English  lansuase  companion  document  to  the  specifications  and 
their  associated  mappings. 

In  addition  to  the  formal  specifications*  the  sovernment  will  be  pro¬ 
vided  with  the  annotated  proofs.  These  proofs  will  show  that  the  trans¬ 
forms  for  the  Kernel  and  Trusted  Processes  preserve  the  security  cor¬ 
rectness  criterion  as  an  invariant.  The  second  level  specifications 
will  be  shown  to  be  consistent  with  the  Top  Level  Specifications. 

If  reauested  by  the  sovernment*  additional  formal  analysis  could  have 
been  performed  to  prove  the  internal  self-consistency  of  the  transforms. 
This  analysis  involves  provins  the  truth  of  a  set  of  automatically 
Senerated  existential  self-consistency  conjectures. 

Finally*  documentation  will  be  produced  detailins  the  correspondence 
between  the  verified  formal  specifications  and  the  implementation. 

Accompanying  this  documentation  will  be  an  analysis  of  any  known  securi¬ 
ty  anomalies  or  deficiencies  in  the  KVH  design  or  implementation.  This 
latter  report  will  include  a  listing  of  usage  restrictions  on  KVH  imple¬ 
mentations*  and  all  known  covert  signalling  channels  along  with  their 
estimated  worst-case  bandwidths.  Because  of  the  nature  of  its  contents » 


the  sovernaent  aaw  reauire  that  this  report  ba  published  as  a  classified 
docuaent « 

4*3*4  Preparation  for  Cartif ication 

Tha  KVH  Bata  systea  ralaasad  in  July  1982  will  ba  a  tunadf  user-oriented 
swstaa  that  is  assantiallw  coapatible  with  VH/370  Ralaasa  3  PLC  15»<22> 
KVH  Bata  will  support  special-access  passwords^  and  prepare  protacted 
audit  trails  for  aach  aini-disk*  Tha  audit  trail  for  aach  aini-disk  to 
which  a  subJact  has  writtan  data  will  contain  data  froa  tha  classifica¬ 
tion  haadar  for  thosa  aini-disks  to  which  tha  subJact  had  raad  accass 
during  his  session*  in  concart  with  tha  KVH  security  policy*  This  data 
can  ba  usad  to  aid  tha  sacurity  officar  in  Justifying  tha  classification 
of  a  aini-disk*  KVH  Bata  will  support  dial-up  accass  terainals* 
although  cartain  installations  aay  alact  to  not  anabla  this  faatura* 

Tha  Top-Level  Spacif ications  and  tha  rafinad  Sacond  Laval  Spacif ications 
will  hava  baan  formally  varifiad  asainst  thair  corractnass  critaria* 
KVH  Bata  will  assantially  ba  raady  for  subaission  for  considaration  for 
cartif ication  in  aulti-laval  anvironaants  as  wall  as  for  protractad 
panatration  analysis  by  outsida  agencies* 


<22> 

Tha  coaaarcially  available  version  of  VH/370  paraits  tha  user  to 
perfora  cartain  operations  which  result  in  his  assuaina  supervisor  state 
on  tha  coaputer*  Since  tha  KVH  Kernel  prevents  these  penetrations  froa 
occurring  by  not  supporting  these  operations*  there  are  incoapatibili- 
tias  between  tha  two  swstaas* 


The  remaining  step  rcauired  to  satisfy  certification  submission  reauire- 
•ents  is  a  demonstration  of  the  correspondence  between  the  KVH  implemen¬ 
tation  and  its  specification*  During  the  formal  verification  activi¬ 
ties*  it  is  possible  that  the  formal  specifications  will  have  been  modi¬ 
fied  in  order  to  achieve  verif ication.  The  implementors  will  have  been 
notified  by  the  verification  staff  of  such  modifications*  and  attempts 
will  have  been  made  to  make  corresponding  modifications  to  the  HOL 
implementation*  However*  there  may  still  exist  discrepancies  between 
the  verified  formal  specifications  and  the  HOL  code. 

A  final  manual  pass  will  be  made  over  the  KVH  Kernel  and  Trusted  Process 
code  in  order  to  ensure  that  the  reouired  correspondences  are  perspicu¬ 
ously  consistent  with  the  specifications.  The  transformations  between 
Ina  Jo  specification  constructs  and  JOVIAL  J3  constructs  will  be  docu¬ 
mented.  '  Any  non-obvious  transf ormations*  made  in  the  name  of  effici¬ 
ency*  will  be  explicitly  documented. 

4.3.3  Maintenance  Support 

It  is  not  expected  that  the  test  site  will  immediately  Place  heavy 
demands  or  expectations  on  the  initial  release  of  KVH  Alpha.  While 
recognizing  that  KVH  Alpha  is  a  prototype  system*  SDC  will  provide  a 
moderate  level  of  support  and  maintenance  to  the  selected  test  site 
during  the  period  of  KVM's  evolution  from  KVH  Alpha  to  KVH  Beta. 

Once  KVH  has  been  tested  and  tuned*  it  will  have  reached  the  release 
stage.  At  this  point*  the  government  plans  to  release  a  Reouest  For 
Proposal  to  the  software  community  for  the  purpose  of  selecting*  as  was 
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don*  in  th*  css*  of  th*  K*rn*liz*d  S*cur*  Operating  System'  sn  orsaniza- 
tion  that  will  professionally  support  and  aaintain  th*  releases  of  KVH 
in  its  installations* 

4*3*6  Documentation 

KVH  system  documentation  will  be  updated  so  that  it  correctly  represents 
th*  KVM-Beta  Release  of  the  system*  In  order  to  support  th*  KVH  main¬ 
tenance  staff*  we  will  produce  a  set  of  'difference*  or  'exception* 
documents  to  complement  IBM's  existins  Release  3  PLC  15  VM/370  Control 
Program  system  maintenance  documentation* 

A  User's  Guide  to  the  security  features  of  KVM»  as  well  as  documents  for 
th*  System  Security  Officer  and  for  computer  operators  will  also  be 
produced* 

SDC  will  maintain  an  internal  project  record  documenting  th*  installa¬ 
tion  and  checkout  experience  of  th*  KVH  Alpha  test  site*  The  objective 
of  this  effort  will  be  to  identify  conf isuration-specif ic/installation- 
specific  anomalies  in  order  to  establish  direct  system  installation  pro¬ 
cedures  that  will  efficaciously  circumvent  both  common  and  site-unieu* 
problems  for  installing  future  versions  of  KVH* 

4*3*7  KVH  Upgrade  to  Support  Selected  VM/370  Release  6  Peripherals 

KVH  Beta  will  be  upgraded  to  support  some  devices  not  supported  by 
Release  3  PLC  15  of  VM/370*  Included  in  this  set  are  the  IBM  3278 
terminal'  and  a  number  of  new  storage  devices  such  as  the  IBM  3370 


series  disks* 


Coarletion  of  the  aodif ications  to  KVM  device  support  will  rerait  KVM 


Bata  to  execute  on  tha  IBM  43xx  series  aainfraae* 
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should  like  to  thank  tha  following  individuals?  S.  Aaas?  J.  P. 
Anderson?  C.  Andresen?  P.  Back?  R*  Bilak?  E»  Book?  M.  Branstadt?  E. 
Burke?  U.  E.  Carlson?  P.  Cohan?  M.  Corasick?  T.  C.  Oarr?  S*  Durowski? 
D»  Edwards?  U.  Eisner?  J.  Fersusson?  J.  Frales?  J.  Frustaca?  G. 
Fullerton?  N*  Hards?  D»  Hollingworth?  G.  Goldberg?  J.  Grawa?  J.  M. 
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Ives ?  A.  K .  Jones?  8.  Lanpson?  J.  Lathrur?  H.  C»  Lauer?  T.  M.  P.  Lacy 
R.  E«  Lyons?  E.  J.  McCauley?  D.  McIntyre?  C.  A*  Melkerson?  M. 
Moriconi?  P.  J.  Neuaann?  M.  J.  Orcewre?  Q»  J*  Porek?  S.  A.  RaJunasr 

C.  A.  Savant?  W*  M.  Shasberaer?  S <  J.  Sharaany  L •  Stansy  P.  Taskary 

D.  H.  Thonpson?  U.  Wilson?  J*  P.  L.  Uooduardy  J*  Wright?  J.  H.  Yotty 
and  D.  Zuckar.  Ua  would  also  lika  to  axtand  our  appreciation  to  our 
technical  editory  J.  A.  Stain)  and  to  J.  Brookshiray  L.  L.  Parris  and 
N.  Spies?  who  provided  typing  support* 
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MISSION 

of 

Rome  Air  Development  Center 

RADC  plant*  and  execute*  research,  development,  tut  and 
selected  acquisition  programs  in.  support  of  Command,  Control 
Communication*  and  Intelligence  (C5T)  activities.  Technical 
and  engineering  support  utithin  area*  of  technical  competence 
i*  provided  to  ESP  Program  Office*  IPO*}  and  other  ESP 
element*.  The  principal  technical  mi**ion  area*  are 
communication*,  electromagnetic  guidance  and  control,  sur- 
veillance  of  ground  and  aerospace  object*,  intelligence  data 
collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  science*,  microuiave 
physics  and  electronic  reliability,  maintainability  and 
compatibility. 


